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1. INTRODUCTION 

1.1 PURPOSE 

The purpose of this paper is to report on the findings of the study of the relation¬ 
ships between CALS and Concurrent Engineering and to recommend to the CALS Policy 
office how best to support concurrent engineering. It is intended to satisfy paragraph 4.d 
of IDA Task order T-B5-602, amendment 5. 

1.2 SCOPE 

The scope of this paper is limited by the level of effort established at the initiation 
of the project. As a result, not all relationships between CALS and Concurrent 
Engineering have been explored. This study is limited to a high-level view of the two prin¬ 
ciple relationships between CALS and Concurrent Engineering, namely multi-enterprise 
information frameworks and individual information exchange standards. 

1.3 APPROACH 

The approach to preparing this paper was to survey relevant CALS and con¬ 
current engineering literature, including the data and workshops used in preparing the 
IDA Report, R-338, The Role of Concurrent Engineering in Weapons System Acquisition 
[WIN88] which contains the definition of Concurrent Engineering used here. The CALS 
information was derived from MIL-HDBK-59, interviews with the CALS Director, two 
CALS conferences, and interviews with two DoD industry representatives to the Industry 
CALS/Concurrent Engineering Steering Group. 

1.4 BACKGROUND 

The Department of Defense is addressing the serious issues of how to increase 
the quality and decrease the cost and schedule of its weapon systems developments. 
CALS and Concurrent Engineering address these issues at different levels. 

Major weapons systems now typically require ten to fifteen years to develop and 
deploy. To successfully develop effective weapons systems and to remain competitive in 
the global market, the time to develop major weapons systems must be substantially 
reduced. Concurrent engineering is an approach to decreasing costs, increasing quality, 
and decreasing schedule by improving the engineering process. The Undersecretary of 





Defense (Acquisition) issued a policy memorandum on March 9, 1989 that stated DoD’s 
intent to encourage the use of Concurrent Engineering in system developments (See 
Appendix A). This intent has been reinforced by the current USD(A) and the current 
Deputy Secretary of Defense. 

Updating and maintaining system documentation has become a significant issue 
in its own right, requiring an inordinate amount of manpower and expense simply to 
maintain and distribute. For example, the onboard documentation for some ships now 
weighs as much as fifty-five tons. The CALS Policy office is moving both government and 
industry data management practice toward compatibility with electronic publishing sys¬ 
tems and making it possible for the government to accept deliveries of weapons system 
documentation in digital form. Future CALS plans aim to integrate this digital data. 

1.4.1 CALS PHASES I & II 

From the Foreward of the CALS military handbook, MIL-HDBK-59 [CAL88, 
iii]: “The purpose of CALS is to improve industry and DoD productivity and quality, and 
thus improve supportability, military readiness, and combat effectiveness . . . . 

The objectives of CALS are 

a. to accelerate the integration of design tools . . . such as those for reliability and main¬ 
tainability into contractor computer-aided design and engineering systems as part of a 
systematic approach that simultaneously addresses the product and its life cycle manufac¬ 
turing and support requirements. 

b. to encourage and accelerate the automation and integration of contractor processes 
for generating weapon system technical data in digital form. 

c. to rapidly increase DoD’s capabilities to receive, store, distribute, and use weapon 
system technical data in digital form to improve life cycle maintenance, training, and 
spare parts reprocurement, and other support processes.” 

These objectives were formulated in 1985 and were included in the CALS military 
handbook when it was published in 1988. The relative importance of the objectives have 
changed. Objective “a”, the acceleration of design tool integration is now a part of the 
Concurrent Engineering effort and a less emphasized effort of CALS. Objective “b” now 
has a higher priority within the CALS program. 

These objectives were further refined in an August 5, 1988 memorandum by 
Deputy Secretary of Defense William H. Taft, IV. That memorandum set forth three 
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specific requirements of all new weapon systems entering development after September 
1988: 

• integration of contractor information systems and processes 

• government access to that information 

• delivery in digital form 

The CALS effort is divided into two phases as described in the CALS Program 
Implementation Guide [CAL88, iii-iv], Near-term (Phase I) goals include . . attain¬ 
ment of increased levels of interfaced, or integrated functional capabilities, and specifica¬ 
tion of requirements for limited government access to contractor data bases, or for 
delivery of technical data to the government in digital form.” Long-term goals (Phase II) 
include “ . . . integration of industry and DoD data bases .... The technology to accom¬ 
plish this will be incrementally developed and proven.” The first phase includes the intent 
to evolve from current paper deliverables to digital deliverables and the second phase is 
intended to integrate the data together. 

1.4.2 CONCURRENT ENGINEERING 

The classic engineering life cycle has four major phases which are performed seri¬ 
ally. The life cycle begins with a requirements phase in which the reason for the product is 
explored, the major issues are surfaced, and its interfaces into other systems are defined. 
Next is a product development phase during which the product is designed. The design 
process normally takes into account many tradeoffs. A process development phase takes 
the design of the product and determines how that product will be economically and reli¬ 
ably manufactured. Finally a prototype phase undertakes an actual build of the product 
to verify all the previous steps. This engineering cycle then feeds into a manufacturing 
cycle which may include redesign because of the realities of full-scale production. 

The serial life cycle has been in use for quite some time, but its shortcomings have 
become apparent in today’s more competitive commercial markets and in a Department 
of Defense environment in which costs and schedules are increasing beyond realistic 
budgeting and military expectations. A well-known problem with this life cycle model is 
that errors in analysis of requirements are often only discovered during the prototype 
phase, by which time much of the funds allocated for research and development have 
been consumed. While the prototype validates all the previous phases of the life cycle, 
little can usually be done to remedy a poor analysis, product design, or process. Even 
when funds to reaccomplish earlier phases of the life cycle have not been expended, the 
time to discover errors is lengthy and is a major obstacle to shortening the product reali¬ 
zation schedule. Finally, little will be known about the performance and producibility 
characteristics and less will be known about the reliability until after a prototype has been 
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built. The problems with this life cycle are serious and must be addressed as they are 
starting to be addressed by the notion of concurrent engineering. 

Concurrent engineering is an attempt to integrate the somewhat independent 
phases of the classic serial life cycle and reorienting the design process toward ensuring 
the efficiency of downstream processes. Specifically, the design of the processes by which 
a product is to be manufactured and supported must be integrated as part of the design of 
the product. 

The IDA Report [V,IN88, 11] defines concurrent engineering as “ ... a sys¬ 
tematic approach to the integrated, concurrent design of products and their related 
processes, including manufacture and support. This approach is intended to cause the 
developers from the outset, to consider all elements of the product life cycle from concep¬ 
tion through disposal, including quality, cost, schedule, and user requirements.” 

Ideally, decisions about the design are optimally placed within the life cycle, but 
the life cycle does not become truly concurrent. The word “concurrent” applies to the 
integration of engineering considerations, not to the life cycle itself. The phases of the 
concurrent engineering life cycle differ from the conventional sequential phases, but 
retain their feed-forward character. They also, however, incorporate feedback of infor¬ 
mation from the downstream activities of manufacturing and support into the upstream 
conceptualization, requirement, and design phases. Concurrent engineering is not an 
engineering discipline in the usual sense but affects the management activities that go into 
supporting a product during the entire life cycle. 1 

Concurrent engineering, as defined, above is a proven product and process 
engineering approach. It causes simultaneous unit and life-cycle cost reductions, quality 
improvement, and schedule reduction. Concurrent engineering succeeds because it 
integrates related activities and focusses then on making sure that the designed product 
can flow through the downstream processes of manufacture, support, and operation effi¬ 
ciently even in the face of uncontrollable factors. When practiced at a world-class 2 level, 
concurrent engineering integrates and focusses on robustness in manufacture, support, 
and use for the purposes of reducing cost and schedule and increasing user perceptions of 
quality. 

The integration of effort in concurrent engineering is over disciplines (e.g., com-, 
puter hardware, software, reliability, thermal, mechanical) and over functions (e.g., 
maintenance, marketing, manufacturing, design). The integration of effort implies a 


1. In particular, concurrent engineering is not "concurrency” of design and production, and idea commonly 
confused with concurrent engineering. 

2. The details of how concurrent engineering is practiced at a world-class level can be found in [CLA89). 
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different information flow from that in a sequential, fractionated process. 

With respect to the information flow in concurrent engineering, Goranson defines 
four possible interpretations of the IDA concurrent engineering definition [GOR]. The 
first is concurrent engineering as management and engineering tools to facilitate team 
approaches. The second is concurrent engineering as communications technologies and 
standards to expand the reach of development teams. The third is concurrent engineer¬ 
ing as data and modeling techniques to allow integrated information bases. The fourth is 
concurrent engineering as fully concurrent, independent simultaneous operations on dis¬ 
tributed master-indexed information. These interpretations span short through long-term 
approaches with corresponding risks and payoffs. 

Thus, concurrent engineering seeks to improve the engineering process by func¬ 
tional and disciplinary integration of the engineering process. It includes a focus on 
engineering quality products by engineering quality processes and an emphasis on con¬ 
tinuous improvement of these processes. Various levels of information integration may 
be used within such an engineering approach. 

1.5 OVERVIEW 

Concurrent engineering can be thought of as the integration of engineering effort 
while CALS is the integration of engineering information. There are two areas of expli¬ 
cit, shared interest between the two initiatives. These are multi-enterprise information 
frameworks and individual information exchange standards, discussed in sections 2.1 and 
2.2. Conclusions and recommendations for further action are found in section 3. The 
Works Consulted section lists all of the documents used in this study. Appendix A con¬ 
tains a copy of the Taft memo which partially defines the CALS program. An article on 
concurrent engineering is reprinted in Appendix B. 










1.6 ACRONYMS 


CALS Computer-aided Acquisition Logistics Support 

DoD Department of Defense 

EDIF Electronic Design Interchange Format 

FMECA Failure Modes Effect Criticality Analysis 

FRACAS Failure Reporting, Analysis, and Corrective System 

IGES Initial Graphics Exchange Standard 

NIST National Institute for Standards and Technology 

OPSEC Operational Security 

PDES Product Data Exchange Specification 

QFD Quality Function Deployment 

R&M Reliability & Maintainability 

SPC Statistical Process Control 

VHDL Very High Speed Integrated Circuit (VHSIC) 
Hardware Description Language 
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2. MULTI-ENTERPRISE INFORMATION FRAMEWORKS 


The CALS program is concerned with the data transfer aspects of weapons sys¬ 
tems developments while the concurrent engineering initiative seeks to change the whole 
life cycle approach. An effective view of this relationship has already been adopted by 
the CALS Policy office: CALS is an enabling or facilitating initiative for several areas of 
process improvement, one of which is concurrent engineering. The obvious relationship 
is that the CALS acceleration of information distribution and delivery will materially 
enhance the efficiency of concurrent engineering processes. Some users of concurrent 
engineering feel that other aspects are more fundamental to cost, schedule, and quality of 
the products, in particular, those having to do with a management approach. The size 
and complexity of DoD system developments, however, indicate a need for vastly 
improved communication and sharing of design information. In fact, every successful 
application of concurrent engineering described in the IDA Report includes attention to 
information integration [WIN88, Appendix A]. 

An information framework is a set of standards and specifications for managing 
engineering information. This information framework sets forth “. . . a structure for 
establishing, storing, executing, and evolving information-based policies and tools” 
[WIN88, 142]. 

An information framework is analogous to a household electric drill where 
engineering tools are analogous to the drill bits. Great economies are produced by stan¬ 
dardizing on \ few common drill bit shaft sizes. No one would consider buying a drill or 
drill bit which was nonstandard because the economies gained by restricting drill bit shaft 
sizes is obvious, but many of our defense software projects use custom information and 
engineering tools and are built to custom specifications. Performance requirements are 
often cited as an argument to substitute a custom for a standard tool. 

The successful evolution of an object-oriented information framework is the cen¬ 
tral issue of CALS Phase II and, in particular, of advanced stages of the PDES, Inc., 
effort. The CALS Phase I effort is aimed at standardizing engineering data into a digital 
form, but without necessarily imparting sufficient semantics to that data to permit 
engineering analysis to be feasible. The CALS Phase II effort attempts to put all the data 
into one logical place, but the question then becomes, “How is all this data to be inter¬ 
preted?” 
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A carefully evolved information framework is necessary to avoid several techno¬ 
logical risks. These risks include the stagnation of information technology through the use 
of inappropriate or outdated standards, the acquisition of weapons system data without 
acquisition of critical information relationships, and the construction of incompatible 
high-performance information tools. 

The information framework then must attempt to avoid these risks by becoming: 


a. adaptable to each installation (i.e., that it can accommodate and 
support the particular tools, engineering functions, and policies of 
each organization). 

b. distributed (i.e., that it can execute on multiple [heterogeneous] 
hosts to maximize performance and availability, can take advantage 
of the distribution of resources and functions in a network, and will 
allow control over resources). 

c. portable (i.e., that it will provide the common functions in different 
hardware/software environments without re-implementation). 

d. extensible (i.e., that it can accommodate new tools, new types of 
engineering information, and new hardware and software technolo¬ 
gies). 

e. evolutionary (i.e., that it can accommodate the technology changes 
in a smooth progression without interrupting users or incurring major 
re-integration costs). [LIN86A, 3-33] 

Developing multi-enterprise information frameworks without an understanding of 
information models or architectures creates a condition where the technology will stop 
evolving. This implies a requirement on the CALS program to develop a common under¬ 
standing of engineering semantics, and to manage the evolution of the standards. These 
standards should be expected to continue to evolve as new technologies develop. 

The CALS program is well-placed to be the central organization to be focussed 
on the development of multi-enterprise information frameworks. CALS appears to be 
taking on this role. The success of concurrent engineering will be influenced by the attain¬ 
ment of the previously listed information framework goals by the CALS Policy office. 

The direction that the CALS program is moving can be described by defining two 
dimensions of the program: integration of data and semantic content of data (See Figure 
1). Each dimension has two states. The first dimension, integration of data, maps the 
phases of the CALS program as it moves from the goal of defining standard data 
exchange formats to the more ambitious goal of integration of databases. The second 
dimension, semantic content of data, shows the transition of information from the syntax 
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only to the syntax and semantics orientation. The semantic information is important 
because it is the semantic information which will make analysis of the data feasible. For 
example, an engineering drawing of a circle within a rectangle is potentially ambiguous: 
it isn’t possible without additional semantic information to decide whether the wire-frame 
diagram represents a circular hc'e within a solid rectangular surface or a solid circular 
shaft within a rectangular space (See Figure 2). 


Integration 


I 

II 

CALS 

Path 

Start 


III 

IV 

PDES 

Path 


Goal 


Figure 1. Two Dimensions of the CALS Program 



Figure 2. Circular Hole or Solid Shaft? 







The intersection of the dimensions’ states produces four sectors as depicted in 
Figure 1. Sector I represents the state of having standard exchange formats for syntax- 
only data, which the CALS Phase I program is now accomplishing. For the purposes of 
this discussion, it is our starting point and for CALS was a reasonable first target. Sector 
II represents the state of the CALS Phase II effort (when it is achieved), where data has 
been amassed and is accessible remotely, and is accessible through logical interfaces. 
Sector III represents the situation where the data has well-defined internal relationships 
and semantics, but is not yet integrated. Sector IV represents the state reached when the 
integrated database (regardless of how implemented) contains information sufficiently 
complete that it can be interpreted by a person or automated tool at a later date with no 
access to the author. 

In order to bootstrap the integration of digital information the strategy of CALS 
Phase I has concentrated on information exchange standards, clearly a prerequisite to 
information integration. 

The mainstream CALS program is moving from Sector I to Sector II, but also 
needs to make the transition to Sector IV. The path to Sector IV can be made from Sec¬ 
tor I via Sector II or it could also be made via Sector III. Currently, the CALS program’s 
direction is to evolve from Sector I, to II, and then to IV. Changing the path to include 
work in Sector III would allow some work in the semantic arena so that results are avail¬ 
able when required. The CALS Policy Office has stated that data exchange with seman¬ 
tics is an objective of PDES, Inc. 

Another fundamental question related to information frameworks arises: is this 
information framework required for the purposes of CALS of the same kind as that desir¬ 
able for concurrent engineering? This may or may not be independent of the similarly 
phrased question about the information required for the two activities. For purposes of 
this discussion an extreme version of CALS objectives is assumed: information is to be 
amassed to allow the government to reprocure parts, subsystems, or systems with 
minimum (ideally, no) reverse engineering. This is fundamentally different from the con¬ 
current engineering objective of making the product realization and support process more 
efficient in that it focusses on one event in the support process. It is beyond the scope of 
this study to detail this issue, but it is known that there are differences of opinion on it and 
it is a topic worthy of discussion in the CALS and CF technical communities. 

2.1 INFORMATION EXCHANGE STANDARDS 

Given the desire for an information framework, there is the separate issue of the 
specific information exchange standards required for the smooth execution of the 
engineering process. Examples of such standards are Very High Speed Integrated Circuit 
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(VHSIC) Hardware Description Language (VHDL), Electronic Design Interchange For¬ 
mat (EDIF), and Initial Graphics Exchange Standard (IGES). 

CALS Phase I has standardized the delivery of images to the government in ras¬ 
ter form. This is a valuable advancement over the current method of delivering micro¬ 
forms. But for future activities, the CALS program has recognized that standardizing at 
the raster level is limiting. 

Standardizing images at the raster level accomplishes a worthy goal, that future 
copies of the images can be produced remotely upon demand and that paper copies don’t 
need to be maintained. But that misses the promise of collecting large masses of data in 
the first place: the promise that, once data is acquired, automatic processes can manipu¬ 
late and analyze it. For example, if all the engineering data for constructing a building is 
stored in a database, then an automated process should be able to analyze the data for 
conformance to building standards. All kinds of questions could be automatically 
answered that would otherwise have to be determined by a manual, error-prone process. 
For instance, “Does the building have enough electrical outlets to meet the building 
code?”, and “Is the structure strong enough to house heavy industrial equipment?” 

In the same way, the database representing an aircraft could permit automated 
processes to deduce answers to questions like “What is the mean time between failure for 
the flight control system?”, “What is the performance envelope predicted for this air¬ 
craft?”, “What is the maximum g-force the aircraft can safely undergo when fully 
fueled?”, “. . . when fuel is nearly empty?”, “What is the current parts availability for 
exchanging the rear stabilizer?” “If the cargo bay area were stretched three feet what 
else would have to change to maintain center-of-gravity?” These questions can be 
answered through a process of analysis, not just through a process of experimentation. 
From a concurrent engineering point of view, it is desirable that more of the process of 
analysis will occur during the design stage, rather than after a prototype is built. By the 
time a prototype is built, changes are difficult and expensive to implement. The schedul¬ 
ing of major design decisions when their downstream impacts can be assessed is central to 
the concept of concurrent engineering and to the consequent production of robust pro¬ 
ducts. 


The Report of the CALS Reliability & Maintainability (R&M) Summer Study on 
Complex Electronics [MDS89, A-l—A-26] lists several R&M functional capabilities 
which represent opportunities for integration. See Figure 3 for some of the automated 
processes that should be able to make use of an extensive weapons system database. 
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Reliability and Maintainability Allocation 

R&M Operational Impact Analysis 

R&M Lessons Learned Data Base 

Serial Reliability Prediction 

System Level Reliability Prediction 

Parts List Verification 

Electrical Stress Analysis 

General Design Rule Checking 

Stress/Fatigue Analysis 

Simulation—Digital 

Simulation—Analog 

Sneak Circuit Analysis 

R&M Model Generators 

Failure Modes Effect Criticality Analysis (FMECA) 

R&M Sensitivity Analysis 
Maintainability Prediction 

Solid Modeling—Equipment Remove/Replace Analysis 
System Level Solid Modeling Accessibility Assessment 
Redundant/Fault Tolerant Design Evaluation 
Testability Analysis 

Testability Fault Isolation Coverage Analysis 
Generation of Test Vectors 

System Level Testability Fault Isolation Coverage Analysis 

Packaging Density Estimation 

Design Decision Traceability 

Producibility Design Analysis 

Environmental Control and Sensitivity Analysis 

First-Cut Reliability Estimator 

Automatic Parts Placement for Thermal Effects Considerations 
Basic Reliability Design Guides 

Reliability Related Shock and Vibration Stress Analysis 
Parts Tolerance Analysis (Design Sensitivity) 

Automated Parts Application Review 

Failure Reporting, Analysis, and Corrective Action System (FRACAS) 
Cooling Effectiveness for Reliability and Power Estimating 
Nuclear Hardening Analysis 
Transient Analysis 


Figure 3. R & M Processes 

These are only a few of the many processes or analysis tools which should be able 
to make use of the weapons system database. Development of these analysis tools would, 
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however, be impeded without the semantic information that is called for in the above 
information framework requirements. The semantic information in a weapons system 
database generally cannot be collected or deduced after the fact and must be “designed 
for” and collected well before any analysis is to begin. A side issue which must be 
resolved is how the semantic data can effectively be put into the PDES database. 

Some electronics design vendors have demonstrated the beginnings of such an 
integrated information framework for electronic circuit design. Using these systems an 
engineer can specify a schematic for an electronic circuit and perform various integrated 
analyses to determine whether physical placement of components will result in violations 
of minimum clearances between boards or between components, whether heat from 
operation of the components will result in temperatures that are unacceptably high or 
lead to unacceptable reliability estimates, and whether vibration modes exist which may 
lead to system failure. These analyses were accomplished in the past through physical 
prototyping or through separate analyses systems. While both of these previous alterna¬ 
tives were fairly slow, with the integrated analysis systems now in use, designs can be 
interactively tested and tuned for reliability, resulting in quick design turnaround. 

Using these analysis tools will change the way designers and managers think 
about their designs. Many managers manage what they can most easily measure. Since 
product reliability, maintainability, survivability, simplicity of manufacture, etc. are more 
difficult and take more time to measure than the usual performance measures of speed, 
size, weight, power and functionality, those difficult-to-define qualities often are not 
effectively managed. One of the benefits of automating the analysis of a design for these 
more abstract measures of performance will be a greater understanding of their role in 
the product life cycle. Furthermore, concurrent engineering requires that these analyses 
be done in concert with rather than in parallel with the product design. Therefore, an 
efficient exchange of design and analysis information between engineering disciplines is 
required. This, in turn, implies well thought-out neutral exchange standards that minim¬ 
ize information loss. 

Of all the different classes of information useful for concurrent engineering and 
that could be standardized, and beyond those already in a standardization process it is 
not yet clear which are of enough common interest to be considered for standardization. 
However, Statistical Process Control (SPC) is already of sufficient interest to warrant 
SPC information representation standardization efforts. Quality Function Deployment 
(QFD) may become widely enough used to warrant the same consideration. 

In discussions at the recent DoD/NIST Workshop on Statistics and Quality 
Methods participants agreed that there are variations in meaning among Statistical 
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Process Control charts that are not obvious from looking at the charts. Differences in 
semantics among popular variations need to be standardized, otherwise the information 
is likely to be misleading. The Electronic Industry Association (EIA) is proposing SPC 
standards which might be suitable as a future CALS standard [EIA89B, EIA89C]. 

The government might consider promoting QFD or a similar method as a way of 
tracking systems engineering information. If that happens, the executing team should 
start considering information exchange formats in the early stages, thus creating a 
defacto proposed standard and avoiding a great deal of useless effort spent in developing 
QFD tools around differing but equivalent information representations. Such tools are 
already available and information exchange among them is impossible. 

Not enough information is available now to determine which other classes of 
information are of sufficient interest to warrant such a standard, but progress could be 
made toward determining which are. The information representations should be specific 
enough to be unambiguous, but not so specific as to overconstrain contractor processes. 

2.2 INFORMATION SECURITY 

One further issue of common interest to the CALS program and within con¬ 
current engineering were described by several people interviewed during this study and is 
appropriate to mention here. Essentially the problem is one of information sharing versus 
information security. Putting detailed information about how to produce and maintain a 
weapon system into electronic form carries new security risks. These concerns arise from 
the unprecedented access now possible through electronic information systems. The 
CALS Policy office is working this issue through the Industry Steering Group. 
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3. CONCLUSIONS AND RECOMMENDATIONS 


1. Standardized semantic information in the CALS weapons system database is 
important and needs to be included in the development of weapons system database 
standards, so that design analysis can be accomplished economically. 

2. The evolution of object-oriented multi-enterprise information frameworks is an 
important factor in the success of the CALS and Concurrent Engineering programs. 

3. SPC information is a good candidate for a standardization effort. 

4. The massive integration of weapons system design and producibility data creates 
new security risks which must be addressed. It is therefore appropriate that CALS 
continues to pursue this issue. 

5. A plan needs to be developed to get all the data associated with manufacture into 
the PDES database. This data needs to include the entire end-to-end manufactur¬ 
ing process. 
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APPENDIX A 


TAFT MEMO 

3 UTY SECRETARY OF DEFENSE 

WASHINGTON, D.C. 20301 


5 AUG 1988 


MEMORANDUM FOR SECRETARIES OF THE MILITARY DEPARTMENTS 

DIRECTOR, DEFENSE LOGISTICS AGENCY 

SUBJECT: Computer-aided Acquisition and Logistic Support (CALS) 

To achieve productivity and quality improvements, my 
September 1985 letter on CALS set the goal of acquiring technical 
data in digital form (rather than paper) for weapon systems 
entering production in 1990 and beyond. We have now taken a 
major step toward routine contractual implementation. The 
Department of Defense (DoD) has coordinated with industry the 
first in a series of CALS issuances of national and international 
standards for digital data delivery and access. These standards 
have been published in MIL-STD-1840A, "Automated Interchange of 
Technical Information," and supporting military specifications. 

The CALS standards will enable either digital data delivery or 
government access to contractor-maintained technical data bases. 

Effective immediately, plans for new weapon systems and 
related major equipment items should include use of the CALS 
standards. Specifically: 

o For systems now in full-scale development or production, 
program managers shall review specific opportunities for 
cost savings or quality improvements that could result from 
changing weapon system paper deliverables to digital 
delivery or access using the CALS standards. 

o For systems entering development after September 1988, 
acquisition plans, solicitations, and related documents 
should require specific schedule and cost proposals for: 

(1) integration of contractor technical information systems 
and processes, (2) authorized government access to contrac¬ 
tor data bases, and (3) delivery of technical information in 
digital form. These proposals shall be given significant 
weight for their cost and quality implications in source 
selection decisions. The CALS standards shall be applied 
for digital data deliverables. 

DoD components shall program for automated systems to 
receive, store, distribute, and use digital weapon system tech¬ 
nical Information, including achieving the earliest possible date 
for digital input to DoD engineering data repositories. These 
systems shall be configured or adapted to support the CALS 
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standards. Plans for CALS implementation and productivity 
improvements will be addressed in Defense Acquisition Board and 
Major Automated Information System Review Council acquisition 
reviews, and in corresponding Service and Agency reviews. 

Each application decision shall be made on its own merits 
with respect to the productivity and quality improvements 
expected at either prime contractor or subcontractor level. The 
Under Secretary (Acquisition) will issue further guidance on 
contract requirements, such as CALS options, in invitations for 
bid; opportunities and safeguards for small business and other 
vendors and subcontractors; government and contractor incentives; 
and funding mechanisms for productivity-enhancing investments in 
automation and CALS integration by defense contractors. 

I believe that CALS is one of the most important and far 
reaching acquisition improvements we have undertaken. I would 
appreciate having the Assistant Secretary (Production and 
Logistics) receive your plan of action within 90 days, including 
identification of systems where opportunities exist for cost 
savings or quality improvement through application of CALS 
technology, the investment required to achieve these benefits, 
and proposed schedules for implementation. 


William H. Taft, IV 


cc; Under Secretary of Defense (Acquisition) 
Assistant Secretaries of Defense 
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ABSTRACT 

This paper summarizes a 1988 investigation of concurrent engineering and its role in weapons system 
acquisition. Concurrent engineering has recently been promoted in the automotive, computer and electronics, 
and aerospace industries as a response to competitive pressures. Viewed as a more systematic approach to 
creating high quality products and bringing them to market at lower cost and in significantly less time, it also 
attracted the attention of the Department of Defense. In 1988, the Institute for Defense Analyses (IDA) was 
asked to investigate concurrent engineering and to identify any advantages that could be expected from applying 
it to weapons system acquisition. 


We describe the investigation, present highlights of the evidence, and set forth the principal findings 
and recommendations. This paper includes the definition of concurrent engineering developed during the 
study. We offer a sample of reported benefits that include 60 percent reduction in product development time, 
elimination of two thirds of the inspectors in one factory, and several million dollars annual savings in chemical 
and soldering processes. We outline the methods and technologies of concurrent engineering—the process 
management ideas, the computer support, and the problem-solving techniques. We provide a conceptual frame¬ 
work to describe the continuing research needed in this area. 


1. INTRODUCTION 

The President’s Blue Ribbon Com¬ 
mission on Defense Management (The 


2. The work reported in this article was conducted as part 
of the Institute for Defense Analyses Project T-B5-602 
under Contract No. MDA 903 84 C 0031 for the 
Department of Defense and first appeared in IDA 
Report R-338, "The Role of Concurrent Engineering in 
Weapons System Acquisition. " The publication of this 
paper does not indicate endorsement by the Department 
of Defense or the Institute for Defense Analyses, nor 
should the contents be construed as reflecting the official 
positions of those organizations. 


Packard Commission) noted that weapons 
systems take too long to develop, cost too 
much to produce, and often do not perform 
as promised or expected. 3 Similar problems 
in automobile and electronics industries 
resulted in a crippling loss of market share by 
United States producers to offshore competi¬ 
tion. Surviving companies in affected 


3. A Quest For Excellence, Final Report to the President 
by the President’s Blue Ribbon Commission on 
Defense Management. June 1986. p. xxii 
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industries responded to competitive pres¬ 
sures by modifying their management, 
engineering, production, and customer sup¬ 
port processes. Many of the modifications 
included a more systematic method of con¬ 
currently designing both the product and the 
downstream processes for producing and 
supporting it. This systematic approach is 
the fundamental theme of concurrent 
engineering. 

In 1988, IDA, at the direction of the 
Undersecretary of Defense for Acquisition, 
examined concurrent engineering and 
presented recommendations to the Depart¬ 
ment of Defense. Our recommendations, 
along with findings of independent groups, 
helped to point out the need for new gui¬ 
dance concerning acquisition. On March 9, 
1989, Dr. Costello, Under Secretary of 
Defense (Acquisition), provided interim pro¬ 
gram acquisition guidance for the Secretaries 
of the Military Departments and their Service 
Acquisition Executives concerning con¬ 
current engineering and its role in the 
acquisition process. The interim guidance 
builds on existing DoD policy to articulate a 
top level approach to integrating the 
engineering processes that support DoD 
acquisition. 

2. APPROACH 

In response to initial reports from 
several companies, the Under Secretary of 
Defense for Acquisition (USD(A)) directed 
that the Institute for Defense Analyses 
(IDA) investigate concurrent engineering 
and its possible application to weapons sys¬ 
tem acquisition. An IDA study team was 
formed and the team, in coordination with 
representatives 4 from industry, academia, 
and government, collected information about 
concurrent engineering. The information 
gathering consisted of literature reviews, site 
visits, and workshops. The IDA study team 
followed the progress of another group that 
presented insights from a cross section of 
industrial officials regarding concurrent 
engineering, particularly senior manage¬ 
ment’s perception of barriers and incentives 


to implementation. [Davi88] 

A report of the initial IDA investiga¬ 
tion was provided to the Department of 
Defense in December 1988. [Winn88] The 
report describes concurrent engineering in 
terms of success stories. It includes case stu¬ 
dies of companies that simultaneously 
improved quality, decreased cost, and 
reduced development time through the appli¬ 
cation of concurrent engineering. 

3. DEFINITION 

Participants at the first IDA con¬ 
current engineering workshop discussed 
concurrent engineering as it is practiced in 
several U.S. companies and developed 
the following definition to describe the 
practice. 

Concurrent engineering is a sys¬ 
tematic approach to the 
integrated, concurrent design of 
products and their related 
processes, including manufac¬ 
ture and support. This 
approach is intended to cause 
the developers, from the outset, 
to consider all elements of the 
product life cycle from concep¬ 
tion through disposal, including 


4. The authors acknowledge the contribution of 
individuals from the following companies: Aerojet 
Ordnance, Allied Signal, AT&T, Boeing, John 
Deere, Ford, Grumman, Hewlett-Packard, 
Honeywell, IBM, ITT, McDonnell Douglas. 
Northrop, and Texas Instruments. We are also 
grateful for the contributions of members of the 
faculties of Carnegie Mellon University, MIT, 
University of Wisconsin-Madison, Princeton. 
University of Chicago, Brigham Young University, 
Harvard Business School, New Jersey Institute of 
Technology, Auburn University, and Rensselaer 
Polytechnic Institute. Scientists and engineers from 
Charles Stark Draper Laboratories, The National 
Science Foundation, The National Center for 
Manufacturing Sciences, the American Supplier 
Institute, the American Statistical Association, the 
National Institute for Standards and Technology, and 
many government scientists and managers also 
helped. Although the contributions of the many 
participants has been substantial, the names of their 
institutions should not be construed as an 
endorsement of this paper or its contents. 
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quality, cost, schedule, and 
user requirements. 

Concurrent engineering is charac¬ 
terized by a focus on the customer’s 
requirements and priorities, a conviction 
that quality is the result of improving a 
process, and a philosophy that improve¬ 
ment of the processes of design, produc¬ 
tion, and support are never-ending 
responsibilities of the entire enterprise. 

The integrated, concurrent design 
of the product and processes is the key to 
concurrent engineering. Figure 1 com¬ 
pares a sequential approach to product 
development, as shown at the top of the 
figure, with a concurrent approach in the 
lower half. In the sequential method, 
information flows are intended to be in 
one direction, from left to right as shown 
by the arrows. In the concurrent 
approach, information flows are bi-direc¬ 
tional and decisions are based on con¬ 
sideration of downstream as well as 
upstream inputs. The companies studied 
in this report found that achieving this 
sharing of information required both 
organizational and technological change. 


Sequential Engineering 



Concurrent Engineering 



The philosophy of concurrent 
engineering is not new. The terms “sys¬ 
tem engineering, “simultaneous engineer¬ 
ing, and “producibility engineering have 
been used to describe similar approaches. 
In fact, a number of authors have 
described similar techniques and hun¬ 
dreds of companies have applied them 
successfully. [Haye88] Nevertheless, 
many companies have not adopted con¬ 
current engineering because of the “fun¬ 
damental, wrenching, far-reaching 
transformations that are required 
throughout the enterprise. 5 

Where changes were made, con¬ 
cern for survival in the face of increased 
competition (particularly from Japanese 
manufacturers) often provided the neces¬ 
sary incentive for companies to improve 
the quality of their products and increase 
the efficiency of their product develop¬ 
ment processes. As the pressure to 
improve quality and efficiency increased, 
newly developed computer-based design 
and analysis tools gave specialists from 
different engineering disciplines the free¬ 
dom of working with the same description 
of the design to evaluate the effects of 
particular design features. The com¬ 
panies that have been successful in con¬ 
current engineering have embraced the 
philosophy of continuing improvement, 
and they are using new tools as well as 
traditional techniques to implement this 
business philosophy. 

Although the study team found 
examples of companies that are moving in 
the direction of concurrent engineering, it 
found no company claiming to have 
developed “the one best way. The people 
affected by the changes say that progress 
has been difficult, that mistakes have 


(ioformuo* now) 


Figure 1 . A Comparison of Sequential 
Concurrent Engineering 


5. Robert H. Hayes, Steven C. Wheelwright, 
and Kim B. Clark, Dynamic Manufacturing, 
The Free Press, New York (1988), p. 344 
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been made, and that enthusiastic advo¬ 
cacy and support by top management 
have been essential. None of the com¬ 
panies said that concurrent engineering, 
in isolation, is capable of producing the 
type of improvements needed to remain 
competitive. Concurrent engineering is 
part of an integrated corporate competi¬ 
tiveness plan that emphasizes concepts 
such as those described by Deming Demi 6 . 
Nevertheless, they are pleased with their 
accomplishments and they are actively 
looking for additional improvements. 

4. METHODS AND TECH¬ 
NIQUES 

The study team identified three 
complementary classes of activities that 
support concurrent engineering: 

• engineering process initiatives 
such as the formation of multidis¬ 
ciplinary teams; 

• computer-based support initia¬ 
tives such as improvement of 
computer-based design tools, 
including giving the user an 
environment that integrates 
separately developed software; 
and 

• use of formal methods including 
application of special purpose 
tools for design and production 
support. 

Engineering process initiatives 
are management actions to improve the 
organization and the procedures used to 
develop a product. Involvement of 
representatives of manufacturing early in 
the design process is a minimal step in this 
direction. Most case studies show that 
companies form teams which include 
marketing, production, engineering, sup¬ 
port, purchasing, and other specialists. 6 
Team members are selected for their abil¬ 
ity to contribute to the design effort by 


early identification of potential problems 
and by timely initiation of actions to avoid 
bottlenecks. The ability to work effec¬ 
tively as a member of a team is critical. 
Using multidisciplinary teams is not 
equivalent to forming committees where 
members often delay decision making; 
instead design teams get faster action 
through early identification and solution 
of problems. 

Leadership at the highest cor¬ 
porate and government levels driving con¬ 
tinuous quality and productivity improve¬ 
ment is a prerequisite for the success of 
the changes associated with these initia¬ 
tives. Changes to the status quo, espe¬ 
cially the cultural changes required for 
concurrent engineering, are not likely to 
be successful or to endure without top 
management leadership and support. 

Most of the companies visited 
during this study have also undertaken 
substantial education efforts in team skills 
and related problem solving techniques. 7 
Other management initiatives include the 
following: 

• emphasizing attention to custo¬ 
mer needs and quality improve¬ 
ment, 

• improving horizontal integration 
of the organization, 

• promoting employee involvement 
in generating new ideas for 
improvement, 

• requiring engineering comparis¬ 
ons of proposed products and 


6. Where companies form long-term partnerships 
with their principal suppliers, they often 
include representatives of the suppliers on the 
design team beginning with the conceptual 
design. 

7 Boeing, Deere, IBM, ITT, McDonnell 
Douglas. Northrop, and Texas Instruments 
Sources of education include local colleges 
and universities, special purpose institutes, 
consultants, and in-house education programs 
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competitive offerings, and 
• establishing closer relationships 
with suppliers to include supplier 
involvement during conceptual 
design phase. 

Computer-based support initia¬ 
tives cover a range of computer-aided 
tools, database systems, special purpose 
computer systems that improve design 
verification, and computer-based support 
of product design, production planning, 
and production. The companies differ in 
the sophistication of their systems, but 
those companies making advances in this 
area share a goal of using a single data 
object as a source for many engineering 
functions including design synthesis and 
verification as well as planning production 
processes. This use of a shared, common 
data object by specialists throughout an 
enterprise provides a mechanism for con¬ 
currently performing the product and pro¬ 
cess design tasks. Feature-based design 
and group technology are approaches to 
creating order and imposing regularity on 
the databases that support the design pro¬ 
cess. 

A solid model of the object being 
designed is frequently used as the single 
data object that allows automated sys¬ 
tems to be integrated. [Wolf87] Some¬ 
times, several companies participating in 
a development team share access to the 
same computer representation of a solid 
model. Mechanical design, tooling, 
machining, and assembly need accurate 
solid models. 

Computer tools that evaluate the 
behavior of potential designs are used 
extensively. Among companies doing 
electronic design, simulation is a critical 
tool. Aircraft companies use finite ele¬ 
ment models (FEM) and computational 
fluid dynamics (CFD) to support design. 


Computer tools not only assist in 
the validation of proposed designs, they 
can also be used in synthesizing the design 
itself. Rule-based systems are sometimes 
used in design synthesis. In attempting to 
provide rule-based design systems, 
several companies 8 are developing practi¬ 
cal applications of expert systems. 

Formal methods 9 are difficult to 
categorize. They include techniques that 
date to the 1930s and more recent 
approaches. Statistical process control 
(SPC) 10 , design of experiments, design- 
for-assembly (developed by Boothroyd 
Dewhurst Inc. [Dewh85] ), value 
engineering and quality function deploy¬ 
ment (QFD) are just a few of the formal 
methods discussed during the study. 

In this group we include com¬ 
puter-based statistical tools for data 
analysis in support of both SPC and 
design of experiment. We also consider 
fundamental engineering philosophies 
such as the robust engineering principles 
as proposed by Taguchi to belong in this 
class. Quality function deployment 
(QFD), and the techniques used by Pugh 
are likewise seen as formal methods. 


8. Litton Axnecom, McDonnell Douglas 
Astronautics, Deere, IBM, AT&T, Texas 
Instrument, ITT, Northrop, and Hughes all 
mentioned some initiative in expert system or 
rule-based design. 

9. See [Winn 88) Appendix B for further 
discussion of the formal methods. 

10. Statistical process control is sometimes 
considered to be applicable only to 
manufacturing processes and not to design or 
service activities. There is abundant evidence 
that SPC provides direct benefits for improving 
a wide range of processes and that it provides 
indirect benefits to the design process when it 
is used in manufacturing. The indirect benefits 
result from feedback of more reliable 
information about manufacturing process 
capabilities and limitations. This information 
is used to design products with characteristics 
that match a company's ability to produce 
them. 
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[Pugh81] 

Other methods that have been useful in 
problem solving include Ishikawa’s 
[Ishi85] seven tools, 11 response surface 
methods, group technology, exploratory 
data analysis, and fault-tree analysis. 

Formal methods are used for dif¬ 
ferent purposes, but they are all designed 
to help people understand the behavior of 
processes, products, mechanisms, and so 
forth, which otherwise could not be under¬ 
stood as thoroughly. If used properly, the 
methods and tools are a tremendous aid 
in design, production, and engineering, 
yielding sharply reduced life cycle costs, 
shortened design cycles, and improved 
quality. 

The apparent diversity of the for¬ 
mal methods sometimes masks the more 
important process that takes place when 
they are used properly. This underlying 
process is the scientific approach to prob¬ 
lem solving. For a company to be suc¬ 
cessful using the approach, its employees 
must develop the habit of identifying 
problems and solving them so as to 
improve the company’s processes. Once 
problems are identified and analyzed, the 
choice of a particular formal method will 
depend on the situation. Box [Box89] 
discusses the paramount importance of 
recognizing that problems represent 
opportunities to gather information to 
improve a process. The following para¬ 
graphs are provided as a brief introduc¬ 
tion to formalized methods. 

An SPC standard was developed 
for the War Department in December 
1940 by the American Standards Associa¬ 
tion. It is a technique for using statistical 
sampling methods to determine the regu¬ 
larity of a process. The original standard 


11 The tools are histograms, cuuse-and-cffect 
diagrams, check sheets, Pareto diagrams, 
graphs, control charts, and scatter diagrams 


was updated and now the use of SPC is 
described in a 1985 ANSI standar- 
dANSI85. 

Design of experiments (experi¬ 
mental design) was invented and 
developed in England in the 1920s by 
Fisher. It has been used in agriculture, 
medicine, and biology. In manufacturing, 
design of experiments provides tools for 
designing and conducting experiments in 
an efficient way so that optimum values 
for product and process parameters can 
be identified. 

Design-for-assembly software is 
commercially available to help designers 
evaluate the benefits of using fewer parts, 
better fasteners, and more efficient 
assembly techniques. One product was 
developed by Boothroyd Dewhurst, Inc. 
[Dewh85] and has been licensed by 
approximately 300 companies in the 
United States and Europe. Many 
dramatic product improvements have 
been reported through its use, particularly 
in the automobile and consumer products 
industries. 

Pugh is a proponent of encourag¬ 
ing creativity during the conceptual design 
stage and using unbiased evaluation cri¬ 
teria to develop the strongest concepts. 

Robust design 12 has come to be 
associated with Taguchi. His engineering 
innovations and statistical methods, how¬ 
ever, can be addressed separately. He 
has introduced several new and very 
important quality engineering ideas. He 


12. The terms robust design, robust engineering, 
and robust product design refer to an 
engineering philosophy that seeks to reduce 
variability of some important characteristic of a 
product in the presence of variability in the 
manufacturing and use environments. It does 
not, unless specifically noted, refer to the 
robustness of an experimental design or of the 
inferences that can be drawn from an 
experiment. 
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stresses the importance of close- 
ness-to-target rather than within-specifi- 
cation objectives. He recommends using 
statistical design to formulate a product 
or process that operates on target with 
smallest variance, is insensitive to 
environmental disturbances and manufac¬ 
turing variances, and has the lowest possi¬ 
ble cost. 13 

Robust design is achieved through 
system design, parameter design, and 
tolerance design. System design is a 
search for the best available technology, 
parameter design selects optimum levels 
for design parameters, and tolerance 
design establishes the manufacturing 
tolerances. [Tagu86] Parameter design 
and tolerance design make use of planned 
experiments. Although there is general 
agreement that the principles of robust 
engineering are an important contribu¬ 
tion, the question of the selection of sta¬ 
tistical methods for conducting the experi¬ 
ments and analyzing the results remains 
open within the scientific community. 14 
The terms “Taguchi Experiments, “Tagu- 
chi Methods, and “Design of Experi¬ 
ments are sometimes used interchange¬ 
ably by practitioners. We use the term 
that was applied by the person who per¬ 
formed the experiment. 

We did not conduct a survey of 
which methods are most widely used in 
the United States. A recent article 
[Kusa88] from Japan describes the sta¬ 
tistical methods mentioned in the presen¬ 
tation to a quality circle conference. The 
most widely used methods were the Ishi- 
kawa tools, design of experiment, and 
tree analysis (QFD). 

One theme that emerged from the 
discussion of methods and technologies, 
particularly from the discussion of formal 
methods, is that there is merit in diversity. 
Participants were in agreement that no 


one set of tools can be expected to serve 
the needs of all users, even within the 
same company. A consensus emerged 
that solutions should be problem cen¬ 
tered, not tool centered. 

4.1 Common Characteristics 

We observed several common 
characteristics in the companies that suc¬ 
cessfully deployed concurrent engineer¬ 
ing: 

• Upper management supported 
the initial change and continued 
to support its implementation. 

• Changes were usually substitu¬ 
tions for previous practices, not 
just additional procedures. 

• The members of the organization 
perceived a need to change. Usu¬ 
ally there was a crisis to be over¬ 
come. Often the motivation 
seemed to center around retaining 
or regaining market share. 

• Companies formed teams for 


13. George E. P. Box, Discussion Section, 
Journal of Quality Technology, Vol. 17, No. 4, 
(October 1985) p. 189. 

14. For an example of such discussions see: Raghu 
N. Kacker, “Off-Line Quality Control, 
Parameter Design and the Taguchi Method, 
Journal of Quality Technology, Vol. 17, No. 4, 
(October 1985), pp. 176-209; Myron Tribus 
and Geza Szonyi, "The Taguchi Methodology: 
An Alternative View (December 1987); 
Romon V. Leon, Anne C. Shoemaker, and 
Raghu N. Kacker, “Performance Measures 
Independent of Adjustment: An Explanation 
and Extension of Taguchi’s Signal-to-Noise 
Ratios, Technometrics, Vol. 29, No. 3 (August 
1987), pp. 253-285; George Box, “Signal-to- 
Noise Ratios, Performance Criteria, and 
Transformations, Technometrics, Vol. 30, No. 
1 (February 1988), pp. 1-40; Ikuro Kusaba, 
“Statistical Methods in Japanese Quality 
Control,” Societas Qualitatis, Vol. 2, No. 2 
(May/June 1988), Union of Japanese Scientists 
and Engineers; and Genichi Taguchi and 
Madhav Phadke, "Quality Engineering 
Through Design Optimization, Conference 
Record, IEEE GLOBECOM 1984 Confer¬ 
ence, Atlanta, Georgia, IEEE, pp 1106-1113. 
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product development. Teams 
included representatives with dif¬ 
ferent expertise, such as design, 
manufacturing, quality assurance, 
purchasing, marketing, field ser¬ 
vice, and computer-aided design 
support. 

• Changes included relaxing poli¬ 
cies that inhibited design changes 
and providing greater authority 
and responsibility to members of 
design teams. Companies prac¬ 
ticing concurrent engineering 
have become more flexible in pro¬ 
duct design, in manufacturing, 
and in support. 

• Companies either started or con¬ 
tinued an existing program of 
education for employees at all 
levels. 

• Employees developed an attitude 
of ownership toward the 
processes in which they were 
involved. 

• Companies used pilot projects to 
identify problems that were asso¬ 
ciated with implementing new 
concurrent engineering techniques 
and to demonstrate their benefits. 

• Companies made a commitment 
to continued improvement. None 
of the companies said it was 
prepared to freeze the latest pro¬ 
cess as the ultimate solution to 
design and production. 

4.2 Misconceptions 

To dispel some misconceptions 
about concurrent engineering, we list 
what concurrent engineering is not. 

First, it is not a magic formula for 
success. The best system cannot compen¬ 
sate for a lack of talent. The companies 
studied have hired and trained engineers 
who are able to identify important design 
parameters, and who are capable of 


creating solutions to problems. At least 
one of the companies said that a signifi¬ 
cant part of their success was the fact that 
people worked harder. Concurrent 
engineering is an approach for improving 
the efficiency of good people who work 
hard; it provides no guarantees of suc¬ 
cess. 

Second, concurrent engineering is 
not the arbitrary elimination of a phase of 
the existing, sequential, feed-forward 
engineering process. For example, it is 
not the simple, but artificial, elimination 
of a test-and-fix phase or of full-scale 
engineering development. Concurrent 
engineering does not eliminate any 
engineering function. In concurrent 
engineering, all downstream processes 
are co-designed toward a more all-encom¬ 
passing, cost-effective optimum design. 

Third, concurrent engineering is 
not simultaneous or overlapped design 
and production. 15 Concurrent engineering 
entails the simultaneous design of the pro¬ 
duct and of the downstream processes. It 
does not entail the simultaneous design of 
the product and the execution of the pro¬ 
duction process, that is, beginning high 
rate production of an item that has not 
completed its test, evaluation, and fix 
phase. On the contrary, concurrent 
engineering emphasizes completion of all 
design efforts prior to production initia¬ 
tion. 

Winner 16 provides a more 


15. At least one spokesperson for manufacturing 
engineers points out that "design continues 
throughout a product’s life, so that even in high 
volume production, the design of the 
production process and the design of the 
product improvements must be coordinated. 
Nevertheless, we continue to hold that 
concurrent engineering does not imply 
beginning production of a product before its 
initial development has reached a stage where 
the design has been validated. 

16. See [Winn 88] pp. 21-23. 


28 






complete list of the misconceptions con¬ 
cerning concurrent engineering that were 
encountered during the initial study 
phase. 

We intentionally avoided creating 
a template or checklist that could provide 
some metric of concurrent engineering. 
Such an approach would offer a tempta¬ 
tion to people who are looking for an easy 
fix. We did not find a foolproof recipe for 
success in using concurrent engineering. 
We believe, however, that companies 
which focus on on the customer’s require¬ 
ments and priorities, are convinced that 
quality is the result of improving a pro¬ 
cess, and hold a philosophy that improve¬ 
ment of the processes of design, produc¬ 
tion, and support are never-ending 
responsibilities of the entire enterprise 
will find themselves practicing something 
closely related to concurrent engineering. 

5. BENEFITS 

During the study, we found evi¬ 
dence that application of concurrent 
engineering methods, as described in the 
case studies, achieved improved quality, 
lower cost, and shorter development 
cycles. 

The next three subsections 
present reported 17 benefits by category: 
quality, cost, and schedule. 

5.1 Quality Improvements 

Several of the companies visited 
during the study reported that their deci¬ 
sion to use concurrent engineering pro¬ 
cedures can be traced to corporate quality 
improvement programs. When these 
companies pursued a vigorous quality pro¬ 
gram to improve their competitive capa¬ 
bilities, they often found that concurrent 


17 The data presented by the companies were 
accepted at face value. 


engineering was a natural part of such a 
program. 

We observed a trend among U.S. 
companies toward accepting the view of 
quality that the Japanese learned from 
such American pioneers as Sarasohn, 
Deming, and Juran. Corporations are 
sending senior executives to Japan and to 
U.S. quality seminars and courses (that 
are often based on Japanese extensions to 
the quality tools originally provided to 
them by American advisors). 

Executives of U.S. companies 
are learning that improving quality does 
not have to drive prices up, but that if 
quality is improved through attention to 
the system (or process) then costs often go 
down. The cost savings result from reduc¬ 
tions in scrap and rework (the elimination 
of the so-called “hidden factory”), 
reduced warranty costs, elimination of 
inspections, and the resulting improve¬ 
ment in production efficiency. The view 
of quality as a driver for competitiveness 
improvements is gaining wider accep¬ 
tance. 

The companies we visited usually 
associate quality of their design with 
fewer engineering changes as the product 
enters high volume production and use. 
They use reduction of scrap and rework 
as a measure of the quality of their pro¬ 
duction processes. Some companies that 
have adopted more strenuous efforts to 
reduce their process variability use other 
measures of quality such as Taguchi’s loss 
function. 

Examples 18 of reported quality 
improvements are listed below: 

• Aerojet Ordnance salvaged 

400,000 pyrotechnic pellets that 


18. A more complete discussion of these cases can 
be found in Appendix A of [Winn 88], 
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would have been discarded 
because of insufficient burn times. 
The pellets could be used because 
Aerojet redesigned the loading 
parameters on the basis of Tagu- 
chi experiments. They improved 
the consistency of tracer rounds 
as measured by \j]o (mean/stan- 
dard deviation) by a factor of 5. 
Their support on one munitions 
program was instrumental in iden¬ 
tifying correct design parameter 
values so that yield was improved 
from approximately 20 percent to 
100 percent, a 400 percent 
improvement. 

• AT&T achieved a fourfold reduc¬ 
tion in variability in a polysilicon 
deposition process for very large 
scale integrated (VLSI) circuits 
(1.75 micron design rules) and 
achieved nearly two orders of 
magnitude reduction in surface 
defects by using Taguchi methods. 

• AT&T reduced defects in the 

5ESS™ programmed digital 
switch up to 87 percent through a 
coordinated quality improvement 
program that included product 
and process redesign. 

• Deere reduced the number of 
inspectors by two thirds by 
emphasizing process control and 
by linking design and manufactur¬ 
ing processes. 

Other reported quality improve¬ 
ments associated with the use of con¬ 
current engineering are described by 
Winner 19 . 

5.2 Cost Reductions 

Reports of cost reduction include 
the following classes of cost savings: 

™ 5ESS is a trademark of AT&T 
19. See (Winn 88] pp. 23-26. 


• Reduced bid in company propo¬ 
sals. 

McDonnell Douglas had 
a 60 percent reduction in life- 
cycle cost and 40 percent reduc¬ 
tion in production cost on a short 
range missile proposal. Boeing 
reduced bid on mobile missile 
launcher and is realizing costs 30 
to 40 percent below bid. 

• Reduced costs in the design 
phase. 

AT&T and IBM reduced 
the number of design iterations 
and made extensive use of com¬ 
puter-aided design verification 
during design saving money and 
time. Deere reduced product 
development cost 30 percent. 

• Reduced costs during fabrication, 
manufacture, and assembly. 

IBM reduced direct labor 
costs in system assembly by 50 
percent. ITT saved 25 percent in 
ferrite core bonding production 
costs. Allied Signal saved more 
than $3,000,000 annually in a bulk 
chemical process as a result of 
experimental design. 

• Costs reduced by parts reduction 
and inventory control. 

Boeing reduced parts 
lead time by 30 percent. AT&T 
reduced parts by one third on sur¬ 
face mount technology (SMT) 
packs and reduced costs to one 
ninth. AT&T Denver Works 
decreased in-process inventory 64 
percent. Deere reduced the 
number of parts to fabricated and 
stocked by 60 to 70 percent. 
Hewlett-Packard Instruments 
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Division recognized inventory 
reductions of 62 percent and a 
productivity increase of 250 per¬ 
cent. 

• Costs reduced by reducing scrap 
and rework. 

Deere reduced scrap and 
rework costs by 60 percent. Using 
a Taguchi experiment, ITT saved 
$400,000 by reducing rejects on 
one product. ITT saved 
$1,100,000 annually by improving 
a soldering process based on a 
Taguchi experiment. 

5.3 Decreased Development Time 

There were many reports of shor¬ 
tened development cycles. Experienced 
engineers pointed out that even signifi¬ 
cantly improved methods will not elim¬ 
inate all the bottlenecks and long lead- 
time items found in some large, complex 
products such as weapons systems. 
Nevertheless, the reported savings indi¬ 
cate that substantial improvements were 
achieved. Samples are listed below: 

• AT&T reduced the total process 
time for the 5ESS Programmed 
Digital Switch by 46 percent in 3 
years. 

• Deere reduced product develop¬ 
ment time for construction equip¬ 
ment by 60 percent. 

• ITT reduced the design cycle for 
an electronic countermeasures 
system by 33 percent, and its tran- 
sition-to-production time by 22 
percent. Time to produce a cer¬ 
tain cable harness was reduced by 
10 percent. 

Winner 20 presents additional 
reports of reduced development times 


20. See [Winn 88|p 27. 


associated with the use of concurrent 
engineering. 

5.4 Interactions 

We found it useful to classify the 
methods and tools associated with con¬ 
current engineering into three categories 
and to describe payoffs in terms of qual¬ 
ity, cost, and schedule improvements. 
These classifications are not intended to 
imply independence. In fact, interactions 
among the approaches are common. We 
found that companies typically employ 
some combination of approaches and they 
experience some mix of benefits. Some of 
these interactions are discussed below. 

• Multifunction teams. The prox¬ 
imity and interaction of personnel 
from the different disciplines 
have a major positive effect by 
itself. Assignment of decision 
responsibility to the team allows 
big improvement in problem reso¬ 
lution which improves product 
and process development times. 

• Systems engineering. Analysis of 
design features and their relation 
to observed reliability and produ- 
cibility is a prerequisite to cross 
training personnel so that they 
achieve a systems perspective. 
The analyses and training are 
essential to quantitative predic¬ 
tions of producibility and reliabil¬ 
ity. Computer support has proven 
useful in performing these ana¬ 
lyses without delaying the design 
process. 

• Computer support. A parts data¬ 
base is valuable in conceptual 
design in terms of evaluating 
options. Product definition and 
shared common product design 
databases are enabling forces for 
a variety of concurrent engineer¬ 
ing functions. Feasibility 





analysis, simulations, integration 
management, design release, and 
transfer to automated production 
processes all support decision 
making throughout the engineer¬ 
ing process. 

• Complexity management. The 
level of program integration and 
complexity affects the leverage of 
concurrent engineering methods 
and techniques. For complex sys¬ 
tems, systems integration must 
address both management and 
design systems. Product and pro¬ 
cess simulations are important at 
the systems level. At the com¬ 
ponent level, process and product 
optimization to achieve robust 
design may be of more immediate 
value. 

• Integration. At the component 
level, concurrent engineering can 
be implemented by integrating the 
design system with a flexible 
manufacturing cell because the 
design and manufacturing systems 
employ features with known vari¬ 
ability. This integration ensures 
that cost, performance, and qual¬ 
ity objectives are met. 

6. PITFALLS 

The benefits cited in this report 
are encouraging, but they have not been 
achieved easily. One employee who is 
familiar with the success story of one of 
the companies encountered in this study 
related some of the mistakes and lessons 
learned in their implementation of con¬ 
current engineering. 

“ . . . really impressive savings 
(hundreds of millions of dollars) remain 
largely unrecognized because they result 
only from improvements of the larger ‘sys¬ 
tems’ over which only top management 
has control. These larger systems include 


policies of the company; training that peo¬ 
ple receive; actions of management; poli¬ 
cies for purchasing parts; barriers 
between departments, between divisions, 
etc.; emphasis on short-term thinking and 
profits; policies for never-ending improve¬ 
ment; the way employees are evaluated; 
fostering of teamwork; and so forth. To 
date, most top managers have failed to 
comprehend, or at least execute, their 
critical responsibility. Their verbal ‘sup¬ 
port’ is simply not sufficient. 

He continues: 

Our corporation’s lack of leader¬ 
ship for concurrent engineering has 
resulted in an effort without any clear 
direction or guidance both within many 
divisions and between the divisions. This 
fosters the widespread perception that 
concurrent engineering is a fad that will 
eventually go away .... 

“Most divisions placed too much 
emphasis on the techniques of concurrent 
engineering (SPC, QFD, Design of 
Experiments, etc.) and not enough 
emphasis on the critical management phi¬ 
losophy underlying the application of the 
techniques. This partly explains the lack 
of top management understanding and 
involvement. Top management views 
concurrent engineering as something the 
lower levels learn and apply .... 

Sometimes the customer’s 
acquisition strategy is a barrier. In one 
case, the customer elected to serve as sys¬ 
tem integrator and to have the program 
office control communication between the 
engineering and manufacturing groups. 
The contract required the engineering and 
manufacturing branches of the company 
to maintain separate relationships with 
the program office. For example, when 
the engineering branch is funded to design 
improvements or modifications for the 
weapon system, the output of this activity 
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is an engineering change proposal (ECP) 
that constitutes a full technical change of 
the technical data package. Depending 
on the nature and scope of the ECP, the 
resulting manufacturing is accomplished 
by the same company or else by another 
vendor. Final assembly is accomplished 
by the manufacturing division of the first 
company. 

This contracting method 
separates engineering from manufacturing 
and, when coupled with a fixed price pro¬ 
duction contract, has several disadvan¬ 
tages for concurrent engineering. First, to 
reduce cost, improve quality, and reduce 
scrap, the company is limited to produc¬ 
tion process changes. Engineering 
changes can only be made if significant 
cost reductions can be demonstrated, at 
which time a value engineering change 
proposal (VECP) is processed by the 
engineering branch and submitted to the 
program manager for approval. The 
result is that engineering changes in pro¬ 
duction are limited to recurring cost 
reduction items where the cost savings 
outweigh the implementation costs on a 
three-year payback. Second, some 
engineering changes are designed by com¬ 
peting engineering houses, so that the pro¬ 
duction organization and processes are 
unknown to the designers. Thus, continu¬ 
ous improvement is stifled and production 
is decoupled from design. In this case, 
the program office, while intending to 
serve as an integrator, was actually a bar¬ 
rier between different divisions of the 
same company. 

A third problem is the expecta¬ 
tion of instant success—an immediate 
reduction in costs with no investment. 
Because more people participate in ear¬ 
lier stages of design, the initial expenses 
of a development project may increase. 
Several companies report that concurrent 
engineering extends th p early design 


effort so the early design functions may 
take more time and cost more. This 
experience was not shared by all practi¬ 
tioners. Even where encountered, its 
effect was compensated by the savings 
when the initial production was started. 
In each reported case, concurrent 
engineering resulted in a shorter overall 
development cycle. 

6.1 Issues 

Members of the working groups 
raised several issues about concurrent 
engineering. Some 21 of the issues are 
listed below: 

Avoid overregulation. Assuming 
that concurrent engineering is a good phi¬ 
losophy for product development, how 
can DoD encourage its use without impos¬ 
ing a particular solution? Senior DoD 
executives can, by including discussions 
of total quality management and con¬ 
current engineering as part of their con¬ 
tinuing dialogue with industry executives, 
show their interest and support for 
improving the development process. 
Beyond demonstrating an interest, a 
statement of DoD policy on concurrent 
engineering, without being overly restric¬ 
tive, is needed. 

Simplify the acquisition process 
while encouraging use of concurrent 
engineering. Both industry and govern¬ 
ment participants expressed a belief that 
creation of additional new programs or 
publication of more regulations without 
eliminating or modifying current practices 
is not the best way to improve the acquisi¬ 
tion process. They expressed a strong 
preference for consolidation, simplifica¬ 
tion, and coordination of existing stan¬ 
dards and regulations, including updating 
the “templates to include concurrent 


21. For a more extensive list of issues see [Winn 
88] pp. 33-35. 46-48, 110, and 125. 




engineering methods. 

Improve the customer-supplier 
relationships in the DoD acquisition pro¬ 
cess. This issue remains open. The bene¬ 
fits of establishing closer relationships 
with suppliers are well known among fol¬ 
lowers of Deming and practitioners of 
just-in-time manufacturing. At the same 
time, the benefits of competition cannot 
be overlooked and support for competi¬ 
tive policies is very strong in the 
Congress. 

Can DoD managers evaluate a 
company’s claims about concurrent 
engineering without imposing a solution? 
Workshop participants from the defense 
industrial base expressed concern about 
their company’s continued ability to com¬ 
pete for DoD contracts. They are ready 
to make the changes that they believe are 
needed to become more competitive, but 
they do not want to start an internal 
improvement program, only to find that 
DoD will later impose some slightly dif¬ 
ferent program. Neither did they want to 
implement some improvement whose 
benefits will not be understood by propo¬ 
sal evaluators. 

7. PRINCIPAL FINDINGS 

The study team reached the ten 
findings listed below. 

7.1 Concurrent Engineering Works. 

The methods and techniques of 
concurrent engineering have been used to 
raise the quality, lower the cost, decrease 
the deployment time, and increase the 
adherence to desired functionality of a 
variety of products. 

Concurrent engineering has been 
used for applications that range from sim¬ 
ple components to complex systems. The 
success of concurrent engineering over 
this variety of applications as well as the 


study team’s understanding of how and 
why concurrent engineering works leads 
to the second finding. 

7.2 Concurrent Engineering Has 
Worked for DoD. 

Concurrent engineering has been 
used in the DoD acquisition process and 
its use was reported to have helped provide 
weapons systems in less time, at lower 
cost, and with higher quality. 

Concurrent engineering methods 
are being used in weapons system projects 
at demonstration/validation, full-scale 
de- velopment, and in produLdon. Nine 22 
of the companies contacted during this 
study provided information that they are 
using concurrent engineering on weapons 
system programs. They are convinced 
that further progress toward a fuller 
implementation of concurrent engineering 
is possible, not only in their companies, 
but throughout the DoD contracting 
environment. 

7.3 Adopting Concurrent Engineering 
Will Not Be Easy. 

There are systemic and individual 
inhibitors to the use of concurrent 
engineering in weapons system acquisi¬ 
tions. 

The inhibitors to using concurrent 
engineering are found in the contractors’ 
organizations and practices as well as in 
DoD’s practices and policies. Capital 
investment decisions, 23 poor horizontal 
communication, local optimizations, and 


22. The companies involved in weapons system 
development and production were Aerojet 
Ordnance, Bell Helicopter, Boeing Aircraft 
(Ballistic Systems Division), General 
Dynamics, Grumman Aircraft, McDonnell 
Douglas, Northrop, ITT Avionics, and Texas 
Instruments. 

23. Robert H. Hayes, Steven C. Wheelwright, 
and Kim B. Clark, Dynamic Manufacturing. 
The Free Press, New York (1088), pp. 61-90. 
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misunderstanding of the importance of 
quality are some of the barriers that must 
be overcome by contractors. Unrealistic 
cost and schedule constraints, excessive 
reliance on specifications and standards, 
and contract language that assumes an 
adversarial relationship between the cus¬ 
tomer and the developer are examples of 
government barriers to using concurrent 
engineering. 24 

7.4 There Is an Opportunity for 
Change. 

The circumstances are right for 
DoD to encourage the further deployment 
of concurrent engineering in weapons sys¬ 
tem acquisitions. 

This follows from an observation 
that commercial industry and, to some 
extent, defense industry have already 
begun to demonstrate success using con¬ 
current engineering. Basic methods of 
concurrent engineering exist and are in 
use and technological support exists. 
Also, the need for developing weapons 
systems in less time at lower cost and with 
the assurance that they will operate satis¬ 
factorily when they are fielded is 
heightened by budget realities. 

7.5 Avoid Past Mistakes. 

Industry experts believe that if 
concurrent engineering becomes a slogan 
or a new area of specialization instead of a 
systematic approach applied across 
engineering disciplines, then the deploy¬ 
ment effort will be counterproductive. 

A broad vision is needed, one 
which can lead to continuous, sustained 
improvement in the engineering processes 
applied to all DoD weapons systems. 


24. For further discussion of barriers see Industrial 
Insights on the DoD Concurrent Engineering 
Program, The Pymaluning Group, Inc. 
(October 1988). 


7.6 Continue Research and Develop¬ 
ment. 

Continued effort is needed to 
develop the methods and technology 
necessary for advances in concurrent 
engineering. 

The need for continued improve¬ 
ment in solid modeling, process-planning 
techniques and computer support, finite 
element modelling, simulation, integra¬ 
tion of computer-based tools, and stan¬ 
dardization of product description seman¬ 
tics was stated at many of the sites 
visited. The Computer-aided Acquisition 
Logistic Support (CALS) initiative has 
encouraged cooperative efforts by indus¬ 
try to develop unified databases and 
integrated design tools, but the results are 
not yet ready for deployment in an open 
market. Many companies are capturing 
lessons learned in the rule and knowledge 
bases that support their design environ¬ 
ments. 

7.7 Help Is Needed. 

Several companies reported that 
funding for IR&D projects intended to 
provide an infrastructure for concurrent 
engineering ' no longer available. 

Companies that implemented ele¬ 
ments of concurrent engineering did so 
either because they were faced with a 
crisis or else they were companies with a 
tradition of continuous improvement for 
whom concurrent engineering is another 
stage in the process. For companies in 
the first category, the crisis provided 
motivation, but changing the way people 
worked was a challenging task. Com¬ 
panies in the second group have esta¬ 
blished programs for encouraging people 
to re-examine their work continually to 
find improvements. 


35 





7.8 Top-level Support Is Essential. 

Implementation of concurrent 
engineering requires top-down commit¬ 
ment across different company functions. 

Because several years may pass 
before company-wide benefits are 
apparent, senior management support is 
essential to prevent premature termina¬ 
tion of new business approaches. Early 
success with pilot projects helps promote 
acceptance of new methods and top-down 
support may be needed to ensure that 
pilot projects are carefully selected and 
adequately supported. 

In each case described to us, a 
company implemented changes by first 
trying new methods on pilot projects. The 
pilot projects serve to identify elements of 
a new plan that need improvement and 
they demonstrate benefits of using new 
techniques. They also served to develop 
the initial cadre of corporate members 
skilled in the new methods. This observa¬ 
tion is consistent with published reports of 
key elements for effecting change. 

7.9 Pilot Projects Can Be Helpful. 

Pilot projects have been useful in 
demonstrating the benefits of concurrent 
engineering. 

With respect to technology, the 
study team considered whether there were 
domains that should be avoided. 

7.10 Concurrent Engineering Is a 
Robust Approach. 

In this study, concurrent 
engineering was found to be useful in a 
range of applications that differed in 
terms of the maturity and type of technol¬ 
ogy used in the product and the produc¬ 
tion process. 

There are some methods, for 
example, that are particularly well suited 


to applications where the technology is 
poorly understood or hard to control. An 
example of this is the application of 
design of experiments to the design and 
production of traveling wave tubes at 
ITT. 

8. RECOMMENDATIONS 

The IDA report [Winn88] con¬ 
tained seven recommendations for the 
Department of Defense. 

• Recommendation 1 

That the Secretary of Defense and 
OSD’s principal acquisition managers act 
to encourage the use of concurrent 
engineering in weapons system acquisi¬ 
tions. 

• Recommendation 2 

That DoD principal acquisition 
managers establish a policy to use con¬ 
current engineering as an implementation 
mechanism for total quality management. 

• Recommendation 3 

That the Office of the Secretary of 
Defense (OSD) should encourage the 
establishment of pilot programs whose 
objectives are to demonstrate that con¬ 
current engineering, when deployed in 
defense industries and applied to DoD 
procurements, has the potential to yield 
higher quality products at a lower cost and 
in a shorter period of time. 

• Recommendation 4 

That OSD, in encouraging the 
implementation of concurrent engineer¬ 
ing, build upon the beneficial aspects of 
existing DoD, national, state, and private 
manufacturing improvement initiatives. 

• Recommendation 5 

That DoD implement an educa¬ 
tion and training effort that starts with the 
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senior OSD acquisition managers and 
then progresses to the lower levels through 
the acquisition chain. Once started at the 
top, lower levels can be trained con¬ 
currently. 

• Recommendation 6 

That DoD encourage industry to 
develop and improve the methods and 
technologies specifically required to sup¬ 
port the use of concurrent engineering in 
weapons system acquisition programs. 

• Recommendation 7 

That OSD acquisition managers 
should initiate a process to identify and 
analyze statutes, rules, regulations, direc¬ 
tives, acquisition procedures, and 
management practices that act as barriers 
or inhibitors to the adoption and use of 
concurrent engineering. 

9 . FUTURE RESEARCH 

At one of the workshops, partici¬ 
pants were asked to identify critical 
research topics to support concurrent 
engineering. Their response showed the 
need for a framework that could relate 
the goals, functions, and capabilities that 
must be in place for concurrent engineer¬ 
ing to succeed. Such a framework was 
developed and is described 25 in the IDA 
report. It describes the technical building 
blocks that provide the capabilities which 
support the critical functions necessary to 
achieve the goals of improving quality 
while simultaneously reducing cost and 
schedule. 

The building blocks are labeled as 
data, information frameworks, tools and 
models, manufacturing processes, and 
design processes. Each category is 
described below. 

25. See Appendix C of (Winn 88]. 


The first area, data, includes the 
kinds of information that needs to be 
brought to the design process for con¬ 
current engineering. There is a require¬ 
ment for a common information architec¬ 
ture so that information users (e.g., 
designers) and information suppliers 
(e.g., maintenance organizations) can 
have a common understanding of the 
meaning of the information. 

The second group, information 
frameworks, consists of a structure of 
specifications and standards for establish¬ 
ing, storing, executing, and evolving infor¬ 
mation-based policies and tools. An 
information framework also has capabili¬ 
ties to organize, access, and evolve the 
data used by the policies and tools. Using 
a conventional or standardized frame¬ 
work that has been designed for evolvabil- 
ity and tailorability allows for easier 
interaction among tools, among 
engineers, among teams, and among 
organizations. DoD has several informa¬ 
tion framework efforts underway. These 
include systems driven by the needs of air¬ 
frame specialists, electronics specialists, 
logisticians, and software engineers. It is 
important that DoD integrate the vision 
of these efforts. 

The third area, tools and models, 
deals with improving the tools directly 
required to support the engineer. The 
report discusses a broad array of empiri¬ 
cal, simulation, and analytical models. 
These include process models, assembly 
and cost models, and manufacturing sys¬ 
tem models. 

The fourth, manufacturing 
processes, addresses improvement efforts 
in integration of the design systems in 
manufacturing cells and systematic tech¬ 
niques for acquiring and analyzing data 
that describe the capabilities and capaci¬ 
ties of the manufacturing systems. This 


includes matters related to flexible 
manufacturing cells, production process 
technologies, and design of experiments 
and other statistical methods. 

The last category, design 
processes, includes work that needs to be 
done to improve understanding of the 
design process itself. This concerns the 
process of design synthesis by the indivi¬ 
dual and group and the psychological and 
sociological phenomena in the execution 
of a team design process. 
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